REMARKS 

The present application was filed on July 11, 2003 with claims 1-21. Claims 1-21 were 
previously canceled without prejudice and replaced by new claims 22-41. Claims 25, 30, 31, 37 
and 41 have since been canceled and claims 42-45 have been added. Claims 22-24, 26-29, 32- 
36, 38-40 and 42-45 are pending. Claims 22, 29, 34 and 38 are the pending independent claims. 

Claims 29, 32, 33 and 43 are rejected under 35 U.S.C. § 103(a) as unpatentable over U.S. 
Patent No. 5,821,936 (hereinafter "Shaffer") in view of Debvec et al., "Design and Evaluation of 
an Evaluation of an Adaptive Icon Toolbar," User Modeling and User-Adapted Interaction, Vol. 
6, No. 1, pp. 1-21, March 1996 (hereinafter "Debvec"). 

Claims 22-24, 26-28, 34-36, 42 and 44-45 are rejected 35 U.S.C. § 103(a) as unpatentable 
over Shaffer and Debvec in view of U.S. Patent Application Publication No. 2002/0151992 
(hereinafter "Hoffberg"). 

Independent claim 29 specifies an arrangement wherein the step of replacing the current 
menu structure with the new menu structure is executed only if the number of menu items in the 
new menu structure that have no corresponding match in the current menu structure exceeds a 
threshold greater than or equal to two menu items. 

The Examiner concedes that Shaffer fails to teach these limitations but rather relies on the 
last two paragraphs of page 4 of Debvec, which the Examiner characterizes as "clearly 
indicat[ing] that the user may choose to disregard the predefined threshold and only consider 
toolbar changes at their convenience, thus indicating that the threshold may be user defined (e.g. 
the threshold may be set [sic] two or more by the user)." The cited portion of Debvec states: 

Once the bar background indicates that a proposal for change is available, 
the user can review the proposal at any time by double-clicking on the bar 
background. This action calls up a single dialog box (Figure 2) that allows the 
user to confirm or reject the proposed change. If the user rejects a proposed 
change, the system maintains the data that led to the suggestion, but then uses this 
data to generate different proposals that have not yet been rejected. This 
mechanism helps prevent the system from insisting on one particular suggestion 
over and over again. . . . 

If the user continues working for a long time without reviewing any 
proposals for change, the system continues to dynamically calculate the priority of 
each command. If at some later time, the user clicks on the bar background to 
review a proposal, the system presents a single proposal based on the user's most 
recent activity. 
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It is important to note that Debvec only presents, and only implements, one proposal at a 
time, regardless of the number of previous proposals which have been rejected and/or ignored by 
the user: "at some later time, the user clicks on the bar background to review a proposal, the 
system presents a single proposal based on the user's most recent activity ." See also Debvec at 
page 5, second paragraph: "When the user accepts the proposed adaptation, the bar background 
returns to its normal color. If the user clicks on the bar background in this state, the system 
displays a dialog box stating that no suggestions are currently available." 

Moreover, each of these proposals involves the addition, removal, or replacement of a 

single icon , thus meaning that the new menu structure will always have at most one item which 

has no corresponding match in the current menu structure. See FIGS. 1 and 2 of Debvec. See 

also Debvec at page 5, first paragraph: 

If a particular function is used frequently, the system indicates that a 
suggestion is available and proposes adding an icon for that function. Similarly, 
if a function on the bar is not used for a long period of time, the system will 
suggest removing it from the bar. If the both [sic] conditions occur together - a 
function not on the bar is used frequently, and a function on the bar is not used for 
a long time - the system can make a single suggestion to replace the unused icon 
with an icon for the frequently used function. 

Thus, Debvec discloses arrangements where the number of menu items in the new menu 
structure that have no corresponding match in the current menu structure will never exceed a 
threshold greater than or equal to two menu items, and hence clearly fails to meet the limitations 
of claim 29 wherein the step of replacing the current menu structure with the new menu structure 
is executed only if the number of menu items in the new menu structure that have no 
corresponding match in the current menu structure will never exceed a threshold greater than or 
equal to two menu items. 

In view of the above, Applicant respectfully submits that Debvec fails to remedy the 
admitted deficiency of Shaffer so as to reach the limitations of claim 29. 

With regard to independent claims 22, 34 and 38, the Examiner asserts that Hoffberg 
"cures the deficiencies of Schaffer [sic] and Debvec with respect to the limitation" of claim 22 
directed to concurrently displaying the entire new menu structure prior to the completion of the 
replacement of the current menu structure with the new menu structure . See the present Office 
Action at page 2, last paragraph; see also the Advisory Action dated January 22, 2009, in which 
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the Examiner discusses "displaying of the new menu structure to the user in piecemeal fashion, 
as taught by Debvec." 

More particularly, the Examiner argues that "Hoffberg discloses that the menu structure 
which is displayed for approval is the concurrent display of the entire menu structure (See 
Hoffberg, Figure 17, wherein the complete altered menu structure is displayed to the user for 
approval.)." See the present Office Action at page 16, first paragraph. 

Applicant respectfully disagrees with the Examiner's characterization of the relied-upon 
portion of Hoffberg. FIG. 17 of Hoffberg is described at paragraphs 1 144 and 1 145 thereof: 

[A] number of likely choices, based on intelligently determined 
alternatives, as well as adaptation based on determined user preferences, are 
initially presented to the user, along with a menu selection to allow rejection of 
these predicted choices. In this case, the user selects the "reject" selection, and the 
system presents the user with a next predicted desired menu choice. Since the user 
history, in this case, does not provide for another choice of particularly high 
probability, the user is prompted to explicitly choose the program sequence by 
day, time, channel, and duration. The user then enters the starting time for 
recording according to the methods described above. The interface then searches 
its databases regarding the user and broadcast listings to present a most likely 
choice given that parameter, as well as all available alternatives. In this case, the 
user history is of little help, and is not useful for making a prediction. In other 
cases, the system uses its intelligence to "fill in the blanks", which could, of 
course, be rejected by the user if these are inaccurate or inappropriate. The most 
likely choices are then those programs that begin at the selected time. If the user 
had input the channel or network, instead of starting time, then the presented 
choices would be the broadcast schedule of the channel, e.g. channel 5 or Fox, for 
the selected day. 

The user then selects one of the available choices, which completes the 
programming sequence. If no database of broadcasts is available, then the user 
explicitly defines all parameters of the broadcast. When the programming is 
completed, the interface then updates its user database, prompts the user to set the 
VCR to record, by, e.g., inserting a blank or recordable tape. 

In other words, FIG. 17 of Hoffberg is directed toward techniques in which a user is 
presented with a number of available choices of programs to record, and which facilitate user 
selection of a program which is not displayed on that menu. There is no concept of a new menu 
structure which replaces a current menu structure, much less of concurrently displaying an entire 
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new menu structure prior to the completion of the replacement of the current menu structure with 
the new menu structure or of obtaining user approval of the new menu structure as displayed. 

In view of the above, Applicant respectfully submits that Hoffberg fails to remedy the 
admitted deficiency of Shaffer and Debvec so as to reach the limitations of claims 22, 34 and 38. 

Dependent claims 23, 24, 26-28, 32, 33, 35, 36, 39 and 40 are believed patentable at least 
by virtue of their dependency from their respective independent claims, which are believed 
patentable for the reasons identified above. 

As heretofore noted, the Examiner argues in rejecting independent claim 29 that the last 
two paragraphs of page 4 of Debvec "clearly indicates that the user may choose to disregard the 
predefined threshold and only consider toolbar changes at their convenience, thus indicating that 
the threshold may be user defined (e.g. the threshold may be set [sic] two or more by the user)." 
Applicant respectfully submits that, even assuming that the combination of Shaffer and Debvec 
did in fact teach or suggest such an arrangement, the proposed combination would nonetheless 
fail to meet the limitations of claims 42-45 wherein a displaying step is executed only if the 
calculated difference exceeds a threshold, the threshold being a number of menu items greater 
than or equal to two. 

In view of the foregoing, Applicant believes that the present application is in condition 
for allowance, and respectfully requests withdrawal of the aforementioned rejections. 

Respectfully submitted, 

/joseph b. ryan/ 

Date: May 26, 2009 Joseph B. Ryan 

Attorney for Applicant 
Reg. No. 37,922 
Ryan, Mason & Lewis, LLP 
90 Forest Avenue 
Locust Valley, NY 11560 
(516) 759-7517 
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